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Abstract. Synthesis is a particularly challenging problem for concur¬ 
rent programs. At the same time it is a very promising approach, since 
concurrent programs are difficult to get right, or to analyze with tradi¬ 
tional verification techniques. This paper gives an introduction to dis¬ 
tributed synthesis in the setting of Mazurkiewicz traces, and its applica¬ 
tions to decentralized runtime monitoring. 


1 Context 

Modern computing systems are increasingly distributed and heterogeneous. Soft¬ 
ware needs to be able to exploit these advances, providing means for applications 
to be more performant. Traditional concurrent programming paradigms, as in 
Java, are based on threads, shared-memory, and locking mechanisms that guard 
access to common data. More recent paradigms like the reactive programming 
model of Erlang [i] and Scala |35I36] replace shared memory by asynchronous 
message passing, where sending a message is non-blocking. 

In all these concurrent frameworks, writing reliable software is a serious chal¬ 
lenge. Programmers tend to think about code mostly in a sequential way, and 
it is hard to grasp all possible schedulings of events in a concurrent execution. 
For similar reasons, verification and analysis of concurrent programs is a difficult 
task. Testing, which is still the main method for error detection in software, has 
low coverage for concurrent programs. The reason is that bugs in such programs 
are difficult to reproduce: they may happen under very specific thread schedules 
and the likelihood of taking such corner-case schedules is very low. Automated 
verification, such as mo del-checking and other traditional exploration techniques, 
can handle very limited instances of concurrent programs, mostly because of the 
very large number of possible states and of possible interleavings of executions. 

Formal analysis of programs requires as a pre-requisite a clean mathematical 
model for programs. Verification of sequential programs starts usually with an 
abstraction step - reducing the value domains of variables to finite domains, 
viewing conditional branching as non-determinism, etc. Another major simpli¬ 
fication consists in disallowing recursion. This leads to a very robust computa¬ 
tional model, namely finite-state automata and regular languages. Regular lan¬ 
guages of words (and trees) are particularly well understood notions. The deep 
connections between logic and automata revealed by the foundational work of 
Biichi, Rabin, and others, are the main ingredients in automata-based verifica¬ 
tion. 




In program synthesis, the task is to turn a specification into a program that 
is guaranteed to satisfy it. Synthesis can therefore provide solutions that are 
correct by construction. It is thus particularly attractive for designing concur¬ 
rent programs, that are often difficult to get right or to analyze by traditional 
methods. In distributed synthesis, we are given in addition an architecture, and 
the task is to turn the specification into a distributed implementation over this 
architecture. 

Distributed synthesis proves to be a real challenge, and there are at least 
two reasons for this. First, there is no canonical model for concurrent systems, 
simply because there are very different kinds of interactions between processes. 
Compare, for example, multi-threaded shared memory Java programs, to Erlang 
or Scala programs with asynchronous function calls. This issue is connected 
with another, more fundamental reason: techniques for distributed synthesis are 
rather rare, and decidability results are conditioned by the right match between 
the given concurrency model and the kind of questions that we ask. 

Mazurkiewicz traces were introduced in the late seventies by A. Mazurkiewicz 
m as a simple model for concurrency inspired by Petri nets. Within this theory, 
Zielonka’s theorem [45] is a prime example of a result on distributed synthesis. 

This paper gives a brief introduction to Mazurkiewicz traces and to Zielonka’s 
theorem, and describes how this theory can be used in the verification and the 
design of concurrent programs. We focus on the synthesis of concurrent programs 
and its application to decentralized runtime monitoring. 

Monitoring is a more lightweight alternative to mo del-checking and synthe¬ 
sis. The task is to observe the execution of a program in order to detect pos¬ 
sible violations of safety requirements. Monitoring is a prerequisite for control, 
because it can gather information about things that went wrong and about com¬ 
ponents that require repair actions. In programming, monitoring takes the form 
of assertions: an invalidation of an assertion is the first sign that something has 
gone wrong in the system. However, concurrent programs often require asser¬ 
tions concerning several components. A straightforward but impractical way to 
verify such an assertion at runtime is to synchronize the concerned components 
and to inquire about their states. A much better way to do this is to write 
a distributed monitor that deduces the required information by recording and 
exchanging suitable information using the available communication in the pro¬ 
gram. Mazurkiewicz trace theory and Zielonka’s theorem can provide a general, 
and yet practical method for synthesizing distributed monitors. 

Overview of the paper. Section |2l sets the stage by describing some classical 
correctness issues for concurrent programs. Section |3| introduces Mazurkiewicz 
traces, and Section 0| presents some applications to decentralized monitoring. 


2 Distributed models: some motivation 

Concurrent programming models usually consist of entities, like processes or 
threads, that evolve in an asynchronous manner and synchronize on joint events. 


such as access to shared variables, or communication. We start with some il¬ 
lustrating examples from multi-threaded programming, and with some typical 
correctness properties. This will allow us to present the type of questions that 
we want to address. 

A multi-threaded program consists of an arbitrary number of concurrently 
executing threads. We will assume that there is a fixed set T of threads. There is 
no global clock, so threads progress asynchronously. Threads can either perform 
local actions or access the global memory, consisting of shared variables from 
a fixed set X. Possible actions of a thread T G T include reads r(T,x,v) and 
writes w{T,x,v) on a shared variable x € X (for some value v) and acquiring 
acq{T, L), resp. releasing rel(T, L) a lock L. More complex forms of access to the 
shared memory, such as compare-and-set (CAS), are commonly used in lock-free 
programming. We will not use CAS in the remaining of this section, but come 
back to it in Section [31 

Partial orders are a classical abstraction for reasoning about executions of 
multi-threaded programs. The computation on each thread is abstracted out 
by a set of events, and the multi-threaded execution is abstracted in form of 
a partial order on these events. An early example is Lamport’s happens-before 
relation originally described for communicating systems. This relation or¬ 
ders the events on each thread, and the sending of a message before its receive. 
In multi-threaded programs with shared memory, where locks guard the access 
to shared variables, the happens-before relation orders two events if they are 
performed by the same thread or they use the same lock. 

A more formal, general definition of the happens-before relation for programs 
goes as follows. Let E be the set of actions in a program. We will assume through¬ 
out the paper that S is hnite. Depending on the problem that we consider, we 
will assume that there is a binary conflict relation D C E x E between the 
actions of the program. For example, we will have a D b if a and b are per¬ 
formed by the same thread. Starting with a linear execution ai • • • a„ S E* of a 
program, the happens-before relation is the partial order on positions defined as 
the reflexive-transitive closure of the relation {i ^ j \ i < j and D Oj}. As we 
will see in Section [31 if the conflict relation is symmetric, this partial order is a 
Mazurkiewicz trace. 

In the remaining of this section we outline two frequently considered correct¬ 
ness issues for concurrent programs, that will be used as examples for decentral¬ 
ized monitoring in Section [31 

2.1 Race detection 

Race detection is one of the widely studied problems of concurrent software. 
Informally, a race occurs whenever there are conflicting accesses to the same 
variable without proper synchronization. Detecting races is important since ex¬ 
ecutions with races may yield unexpected behaviors, caused by the outcome of 
the computation depending on the schedule of threads. 

In order to define races for multi-threaded programs with lock synchroniza¬ 
tion we need to introduce the happens-before relation for such programs. Let E 


be the set of actions in a program, for instance: 


S = {w{T, x), r{T, x), acq{T, L), rel{T, L) \ T, x, L} . 

Two actions from S are in conflict if 

— they are performed by the same thread, or 

— they acquire or release the same lock. 

A race occurs in an execution if there are two accesses to the same shared 
variable such that 

— they are unordered in the happens-before relation, and 

— at least one of them is a write. 

Example 1. Figure [1] illustrates a race problem due to locking that is too fine¬ 
grained. Two threads have access to a list pointed to by head. Thread 1 adds 
an element to the head of the list, while Thread 2 deletes the head element. The 
two instructions protected by the lock are ordered in the happens-before relation. 
However, tl. next = head and head = head. next are unordered. Since the first 
instruction is a read, and the second a write, this situation is a race condition. 


type list Tint data; list *next} 
list *head 

Thread 2 

7: t2 = head; 

8: ack(lock) 

9: head = head.next 

10: rel(lock) 


Fig. 1. A race condition in the execution 1, 2, 3, 7, 8, 9: events 3 and 9 are unordered in 
the happens-before relation. 


Thread 1 

1: tl = new(list); 
2: tl.data = 42; 

3: tl.next = head; 
4: ack(lock) 

5: head = tl 

6: rel(lock’) 


2.2 Atomicity 

Atomicity, or conflict serializability, is a high-level correctness notion for con¬ 
current programs that has its origins in database transactions. A transaction 
consists of a block of operations, such as reads and writes to shared memory 
variables, that is marked as atomic. An execution of the transaction system 
is serial if transactions are scheduled one after the other, without interleaving 
them. A serial execution reflects the intuition of the programmer, about parts 
of the code marked as transactions as being executed atomically. 




In order to define when a multi-threaded program is conflict-serializable, we 
need first the notion of equivalent executions. Two executions are equivalent if 
they define the same happens-before relation w.r.t. the following conflict relation: 
Two actions from E = {wlT, x),rlT, x) \ T,x} are in conflict if 

— they are performed by the same thread, or 

— they access to the same variable, and at least one of them is a write. 

The above conflict relation has a different purpose than the one used for the 
race problem: here, we are interested in the values that threads compute. Two 
executions are considered to be equivalent if all threads end up with the same 
values of (local and global) variables. Since a write w{T,x) potentially modifies 
the value of x, its order w.r.t. any other access to x should be preserved. This 
guarantees that the values of x are the same in two equivalent executions. 

A program is called conflict-serializable (or atomic) if every execution is 
equivalent to a serial one. As we will explain in Section [3] this means that ev¬ 
ery execution can be reordered into an equivalent one where no transaction is 
interrupted. 

Example 2. Figure [3] shows a simple program with two threads that is not 
conflict-serializable. The interleaved execution where Thread 2 writes after the 
read and before the write of Thread 1, is not equivalent to any serial execution. 


Thread 1 

1: atomic { 

2: read(x); 

3: write(x) 

4: > 


Thread 2 

5: atomic f 
6: write(x); 

7: > 


Fig. 2. A program that is not conflict-serializable: the execution 1, 2, 5, 6, 7, 3, 4 is not 
equivalent to any serial execution. 


3 Mazurkiewicz traces and Zielonka’s theorem 

This section introduces Mazurkiewicz traces |31] , one of the simplest formalisms 
able to describe concurrency. We will see that traces are perfectly suited to 
describe dependency and the happens-before relation. The notion of conflicting 
actions and the happens-before relation seen in the previous section are instances 
of this more abstract approach. 

The definition of traces starts with an alphabet of actions E and a depen¬ 
dence relation D Q E x E on actions, that is reflexive and symmetric. The idea 
behind this relation is that two dependent actions are always ordered, for in¬ 
stance because the outcome of one action affects the other action. For example, 
the actions of acquiring or releasing the same lock are ordered, since a thread 
has to wait for a lock to be released before acquiring it. 




Example 3. Coming back to the problems introduced in Sections 12.11 and 12.21 
note that the conflict relations defined there are both symmetric. For example, we 
can define the dependence relation D over the alphabet S = {r(T,x),w{T,x) \ 

T G T,x £ X} of Section [521 by letting a D b if a,b are in conflict. 

While the dependence relation coincides with the conflict relation, the happens- 
before relation is the Mazurkiewicz trace order. A Mazurkiewicz trace is the la¬ 
belled partial order T{w) = {E, <) obtained from a word w = ai ... Un G X* in 
the following way: 

— E = {ei,..., e„} is the set of events, in one-to-one correspondence with the 

positions of w, where event has label Ui, 

— ^ is the reflexive-transitive closure of {{ei,ej) \ i < j, ai D o^}. 

From a language-theoretical viewpoint, traces are almost as attractive as 
words, and several results from automata and logics generalize from finite and 
infinite words to traces, see e.g. the handbook cni- One of the cornerstone re¬ 
sults in Mazurkiewicz trace theory is based on an elegant notion of finite-state 
distributed automata, Zielonka automata, that we present in the remaining of 
the section. 

Informally, a Zielonka automaton [45] is a finite-state automaton with control 
distributed over several processes that synchronize on shared actions. Synchro¬ 
nization is modeled through a distributed action alphabet. There is no global 
clock: for instance between two synchronizations, two processes can do a differ¬ 
ent number of actions. Because of this, Zielonka automata are also known as 
asynchronous automata. 

A distributed action alphabet on a hnite set P of processes is a pair (E, dom), 
where A is a finite set of actions and dom : S —>■ (2'^ \ 0) is a domain function. 
The domain dom{b) of action b comprises all processes that synchronize in order 
to perform b. The domain function induces a natural dependence relation D over 
E by setting a D b if dom{a)ridom{b) yf 0. The idea behind is that executions of 
two dependent actions affect at least one common process, so their order matters. 
By contrast, two independent actions a,b, i.e., where dom(a) H dom(b) = 0, can 
be executed either as ab or as ba, the order is immaterial. 

Example 4- We reconsider Example [31 The dependence relation D defined there 
can be realized by a distributed alphabet (E, dom) on the following set of pro¬ 
cesses: 

p = ru{(r,x) \T gt,xgx}. 

Informally, each thread T gT represents a process; in addition, there is a process 
for each pair {T, x). The process {T, x) stands for the cached value of x in thread 
T. 

The domain function defined below satishes a D 6 iff dom{a) fl dom{b) yf 0: 


{T,{T,x)} if a = r{T,x) 

{T, (r, x)\T' gT} if o = w{T, x). 


dom[a) 


The intuition behind dom{a) is as follows. A read r(T,x) depends both on the 
internal state of thread T and the cached value of x, and will affect the state of 
T. A write w(T, x) depends on the internal state of thread T and will affect not 
only the state of T, but also the cached values of x on other threads using x, 
since the new value will be written into these caches. 

A Zielonka automaton A = ((S'p)pgp, (s™*)pgp, 5) over {E, dom) consists of: 

— a finite set Sp of (local) states with an initial state G Sp, for every 

process p S P, 

- a transition relation S C Uaei; (npedom(a) x {«} x I\p&dom{a} Sp)- 

For convenience, we abbreviate a tuple (sp)pgp of local states by sp. An 
automaton is called deterministic if the transition relation is a partial function. 

Before explaining the semantics of Zielonka automata, let us comment the 
idea behind the transitions and illustrate it through an example. The reader may 
be more familiar with synchronous products of finite automata, where a joint 
action means that every automaton having this action in its alphabet executes it 
according to its transition relation. Joint transitions in Zielonka automata follow 
a rendez-vous paradigm, meaning that processes having action b in their alphabet 
can exchange information via the execution of b: a transition on b depends on the 
states of all processes executing b. The following example illustrates this effect: 

Example 5. The CAS (compare-and-swap) operation is available as atomic oper¬ 
ation in the JAVA package java.util.concurrent.atomic, and supported by many 
architectures. It takes as parameters the thread identifier T, the variable name x, 
and two values, old and new. The effect of the instruction y = CAS (T, x, old, new) 
is conditional: the value of x is replaced by new if it is equal to old, otherwise 
it does not change. The method returns true if the value changed, and false 
otherwise. 

A CAS instruction can be seen as a synchronization between two processes: 
Pt associated with the thread T, and Px associated with the variable x. The 
states of Pt are valuations of the local variables of T. The states of Px are the 
values X can take. An instruction of the form y = CAS (T,x, old, new) becomes a 
synchronization action between Pt and Px with the two transitions of Figure [3] 
(represented for convenience as Petri net transitions). 

A Zielonka automaton can be seen as a usual finite-state automaton, whose 
set of states S = given by the global states, and transitions s 

s' if € 6, and Sp\dom(a) = SpVdomfa)- ^hus states of this 

automaton are tuples of states of the processes of the Zielonka automaton. As 
a language acceptor, a Zielonka automaton A accepts a trace-closed language 
L{A), that is, a language closed under commuting adjacent independent symbols. 
Formally, a language L is trace-closed when uabv € A if and only if ubav G A, 
for all u,v G E* and all independent actions a, b. 

A cornerstone result in the theory of Mazurkiewicz traces is a construction 
transforming a sequential automaton into an equivalent deterministic Zielonka 


Pt 


Pt 


P. 


P. 




Fig. 3. CAS as transitions of a Zielonka automaton. On the left side of the hgure we 
have the case when the value of x is old; on the right side v is different from old. 
Notice that in state s' the value of y is true, whereas in s", it is false. 


automaton. This beautiful result is one of the rare examples of distributed syn¬ 
thesis with broader scope. 

Theorem 1. Given a distributed alphabet {E, dom), and a regular trace- 
closed language L C E* over (E, dom). A deterministic Zielonka automaton A 
such that L{A) = L can be effectively constructed. 

The only assumption of the theorem above is that the language of the au¬ 
tomaton is trace-closed, but this is unavoidable. Moreover, trace closure can be 
checked easily, e.g. on the minimal DFA of the given language. 

The construction behind Theorem [T] is technically involved, but also very 
fascinating. The crux is to show how to put together distributed information us¬ 
ing additional memory that is Many researchers contributed to simplify 

the construction and to improve its complexity, see |8l33ll9llb| and references 
therein. The most recent construction m produces deterministic Zielonka au¬ 
tomata of size that is exponential in the number of processes (and polynomial 
in the size of a DFA for L). The exponential dependence on the number of pro¬ 
cesses is necessary, modulo a technical assumption (that is actually required for 
monitoring). 

Theorem 2 ( |16] ). There is an algorithm that takes as input a distributed al¬ 
phabet (E, dom) over n processes and a DFA A accepting a trace-closed language 
over (E, dom), and computes an equivalent deterministic Zielonka automaton B 
with at most A" • |A|" states per process. Moreover, the algorithm computes the 
transitions of B on-the-fly in polynomial time. 

4 Distributed monitoring 

The construction of deterministic Zielonka automata opens interesting perspec¬ 
tives for monitoring concurrent programs. In order to monitor a concurrent pro¬ 
gram at runtime, the monitor has to be distributed (or decentralized). This 


^ Vector clocks |30| are a similar notion in distributed computing, but they do not 
require a finite domain of values. 





means that there is a local monitor on each thread, and these local monitors 
can exchange information. The exchange can be implemented by allowing local 
monitors to initiate extra communication, or, more conservatively, by using the 
available communication in the program in order to share monitoring-relevant 
information. We follow the latter setting here, since adding communication can 
reduce the concurrency, and it is very difficult to quantify how much performance 
is lost by adding communication. 

Apart from detecting violations of safety properties at runtime, the infor¬ 
mation gathered by such monitors can be also used to recover from an unsafe 
state. Of course, this can be done only at runtime, and not offline, by inspecting 
sequential executions a posteriori. 

Our general approach for this kind of distributed monitoring is simple: we 
have some trace-closed, regular property (f) that should be satisfied by every 
execution of a given program or system. To detect possible violations of (j) at 
runtime, we construct a monitor for (j) and run it in parallel with the program. 
Consider the scenario where the program P is modeled by a Zielonka automaton 
Ap. If a monitor is also a Zielonka automaton Am, then running the monitor 
M in parallel to P amounts to build the usual product automaton between Ap 
and Am process-wise. 

Interestingly, many properties one is interested to monitor on concurrent pro¬ 
grams can be expressed in terms of the happens-before relation between specific 
events, as the following example illustrates. 

Example 6. Consider the race detection problem from Section [2.1l A race occurs 
when two conflicting accesses to the same variable are unordered in the happens- 
before relation. Therefore, a violation of the “no-race” property is monitored by 
looking for two unordered accesses to the same variable, at least one of them 
being a write. 

Monitoring a violation of atomicity (recall Section is done by checking 
for every transaction on some thread T, that no action c of some thread T' ^ T 
happened after the beginning a = beg(T) of the transaction on T (cf. instruction 
1 of Example [5|) and before its matching end b = end{T) (cf. instruction 4). In 
other words, the monitor looks for events c on T' ^ T satisfying a ^ c ^ & in 
the happens-before relation. 

Determining the partial ordering between specific events is closely related 
to the kernel of all available constructions behind Zielonka’s theorem. This is 
known as the gossip automaton [33], and the name reflects its role: it computes 
what a process knows about the knowledge of other processes. Using finite- 
state gossiping, processes can put together information that is distributed in the 
system, hence reconstruct the execution of the given DFA. 

The gossip automaton is already responsible for the exponential complexity of 
Zielonka automata, in all available constructions. A natural question is whether 
the construction of the gossip automaton can be avoided, or at least simplified. 
Perhaps unsurprisingly, the theorem below shows that gossiping is not needed 
when the communication structure is acyclic. 


The communication graph of a distributed alphabet (S, dom) with unary or 
binary action domains is the undirected graph where vertices are the processes, 
and edges relate processes p ^ qii there is some action a & S such that dom {a) = 

{P, 91- 

Theorem 3 ( (23) 1. Let (E, dom) be a distributed alphabet with acyclic commu¬ 
nication graph. Every regular, trace-closed language L over E can be aeeepted 
by a deterministic Zielonka automaton with O(s^) states per process, where s is 
the size of the minimal DFA for L. 

The theorem above can be useful to monitor programs with acyclic com¬ 
munication if we can start from a small DFA for the trace-closed language L 
representing the monitoring property. However, in some cases the DFA is neces¬ 
sarily large because it needs to take into account many interleavings. For exam¬ 
ple, monitoring for some unordered occurrences of b and c, requires a DFA to 
remember sets of actions. In this case it is more efficient to start with a descrip¬ 
tion of L by partial orders. We discuss a solution for this setting in Section |4T] 
below. 

We need to emphasize that using Zielonka automata for monitoring proper¬ 
ties in practice does not depend only on the efficiency of the constructions from 
the above theorems. In addition to determinism, further properties are desirable 
when building monitoring automata. The first requirement is that a violation of 
the property to monitor should be detectable locally. The reason for this is that 
a thread that knows about the failure can start some recovery actions or inform 
other threads about the failure. Zielonka automata satisfying this property are 
called locally rejecting US]. More formally, each process p has a subset of states 
Rp Q Sp', an execution leads a process p into a state from Rp if and only if p 
knows already that the execution cannot be extended to a trace in L(A). The 
second important requirement is that the monitoring automaton Am should 
not block the monitored system. This can be achieved by asking that in every 
global state of Am such that no process is in a rejecting state, every action is 
enabled. A related discussion on desirable properties of Zielonka automata and 
on implementating the construction of [16] is reported in [2]. 

4.1 Gossip in trees 

In this section we describe a setting where we can compute efficiently the happens- 
before relation for selected actions of a concurrent program. We will first illus¬ 
trate the idea on the simple example of Section 12.21 The program there has 
two threads, Ti and T 2 , and one shared variable x. For clarity we add actions 
beg{Ti), end{Ti) denoting the begin/end of the atomic section on R. Thus, the 
alphabet of actions is: 

E = {beg{Ti), end{Ti),w{Ti,x),r(Ti,x), beg{T 2 ), end{T 2 ),w{T 2 ,x)} . 

The dependence relation D includes all pairs of actions of the same thread, as 
well as the pairs {r{Ti,x),w{T 2 ,x)) and {w(Ti,x),w(T 2 ,x)). Following Exam¬ 
ple S] the Zielonka automaton has processes P = {Ti, T 2 , {Ti,x), (T 2 , a;)} and the 


domains of actions are: 


dom{beg{Ti)) = dom{end{Ti)) = {Ti}, 
dom{r{Ti,x)) = {Ti, {Ti,x)} 
dom{w{Ti,x)) = {Ti, {Ti,x), {T 3 -i,x)} 

Note that we can represent these four processes as a (line) tree in which the 
domain of each action spans a connected part of the tree, see Figured) 


{T2,x) 


T2 


Ti 


{Ti,x)' 


Fig. 4. A tree of processes T. The dashed part is the domain of the read action, whereas 
the dotted parts are the domains of the two writes. 


The Mazurkiewicz trace in Figured represented as a partial order, shows a 
violation of conflict serializability: event c at step 6 satisfies a c ^ b, where 
a represents step 1, and b step 4. The happens-before relation can be computed 
piecewise by a Zielonka automaton, by exchanging information via the synchro¬ 
nization actions. Figure[6]illustrates how processes update their knowledge about 
the partial order. Note how the two partial orders represented by thick lines, are 
combined together with the action w(T 2 ,x) of step 6, in order to produce the 
partial orders of processes {Ti,x), (T 2 ,x) and T 2 in the last column. Thus, after 
step 6 these processes know that action w{T 2 ,x) happened after heg(Ti). Exe¬ 
cuting then steps 3 and 4 will inform process Ti about the violation of conflict 
serializability. 


1 

beg{Ti) 


5 

beg{T2) 


2 


3 


■►r(Ti,x) w{Ti,x) 



w{T2,x) 


4 

end{T\) 


Fig. 5. Violation of conflict serializability (partial order). 


Gossiping in trees of processes works more generally as follows. We call a 
distributed alphabet [S, dom) over process set P tree-like, if there exists some 
tree T with P as set of vertices, such that the domain of each action is a connected 
part of T. 

Note that the tree T is uniquely defined by action domains in the special 
case where the actions have at most binary domains. Otherwise, there can be 












several trees as above, but we will assume that the distributed alphabet comes 
with a suitable tree representation. 

We are also given a set of monitoring actions F C S. The task is to compute 
for each process p S P the happens-before relation w.r.t. F, in other words the 
happens-before relation between the most recent occurrences of actions from F 
that are known to process p. This information is a DAG where the set of nodes 
is a subset of F. Figure [5] below gives an example of such a computation. 

Theorem 4. Given a tree-like distributed alphabet (S, dom) with tree T, and 
a set F C S of actions. The happens-before relation w.r.t. F can be computed 
by a Zielonka automaton where every process p maintains two DAGs of size 
|T| + out{p), with out{p) the out-degree of p in F. Each update of the DAGs can 
be done in linear time in their size. 

Theorem 2] provides a rather simple way of reconstructing the happens-before 
relation with finite additional memory, and in a distributed way. Each synchro¬ 
nization action b will update the DAGs maintained by the processes executing &, 
by combining these DAGs and selecting the most recent knowledge about actions 
of F. As an example, suppose that processes p and q are neighbors in the tree, 
say, q is the father of p. As long as there is no synchronization involving both p 
and q, process p has the most recent knowledge about occurrences of T-actions 
belonging to processes in the subtree of p. As soon as some action synchronizes 
p and q, process q will be able to include p’s knowledge regarding these actions, 
in its own knowledge. 


5 Related work 

This brief overview aimed at presenting the motivation behind distributed syn¬ 
thesis and how Mazurkiewicz trace theory can be used for monitoring concurrent 
programs. To conclude we point out some further related results. 

Our discussion turned around distributed synthesis in a simple case where 
the program evolves without external actions from an environment. Synthesis 
of open systems, i.e., systems with an environment, is a more complex prob¬ 
lem. Synthesis started as a problem in logics, with Ghurch’s problem asking for 
an algorithm to construct devices that transform sequences of input bits into 
sequences of output bits, so that the interaction conforms to a given logical 
formula [7]- Later, Ramadge and Wonham proposed the supervisory control for¬ 
mulation [42] , where a plant and a specification are given; a controller should be 
designed such that its product with the plant satisfies the specification, no mat¬ 
ter what the environment does. Synthesis is a particular case of control where 
the plant allows for every possible behavior. Rabin’s result on the decidability 
of monadic second-order logic over infinite trees answered Ghurch’s question for 
MSO specifications [41]. 

Synthesis without environment. The problem of distributed synthesis without 
environment was first raised in the context of Petri nets. The task there is to 
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Fig. 6. Computing the partial order. Numbers in the first line stand for the program 
lines in Example [2l Dots mean that the information does not change. 


decide whether an automaton, viewed as a graph, is isomorphic to the marking 
graph of a net. Ehrenfeucht and Rozenberg introduced the notion of regions, 
that determines how to decompose a graph for obtaining a net m- 

Zielonka’s algorithm has been applied to solve the synthesis problem for 
models that go beyond Mazurkiewicz traces. One example is synthesis of com¬ 
municating automata from graphical specifications known as message sequence 
charts. Communicating automata are distributed finite-state automata commu¬ 
nicating over point-to-point FIFO channels. As such, the model is Turing power¬ 
ful. However, if the communication channels are bounded, there is a tight link be¬ 
tween execution sequences of the communicating automaton and Mazurkiewicz 
traces [12]. Actually we can handle even the case where the assumption about 
bounded channels is relaxed by asking that they are bounded for at least one 
scheduling of message receptions m- Producer-consumer behaviors are captured 
by this relaxed requirement. 

Multiply nested words with various kinds of bounds on stack access 140125126] . 
are an attractive model for concurrent programs with recursion, because of de¬ 
cidability properties and expressiveness. In |5| the model is extended to nested 
Mazurkiewicz traces and Zielonka’s construction is lifted to this setting. 

For runtime monitoring, a similar approach as ours is advocated in |43j . 
that proposes an epistemic temporal logic for describing safety properties. A 
distributed implementation of a monitor for such properties is obtained, based 
on a variant of vector clocks. 
















Synthesis with environment. One way to lift Church’s problem to the distributed 
setting was proposed by Pnueli and Rosner [33]. They showed that synthesis 
is decidable for very restricted architectures, namely pipelines. General unde¬ 
cidability was already known from the framework on multi-player games |38| . 
Subsequently, [28] showed that pipelines are essentially the only decidable case. 
Some interesting extensions of Pnueli and Rosner’s setting have been considered 
in |24ll3llh| . 

Alternatively, a distributed formulation of Church’s problem can be for¬ 
mulated in Ramadge and Wonham’s supervisory control setting. This prob¬ 
lem, when plants and controllers are Zielonka automata, has been considered 
in |14I29I17I34] . In this formulation, local controllers exchange information when 
synchronizing on shared actions. In this way, the arguments for undecidability 
based on hidden information, as in [39138] . do not apply. Decidability of dis¬ 
tributed control for Zielonka automata is still open. It is known though that this 
formulation admits more decidable architectures: the control problem for local 
parity specifications is decidable over acyclic architectures [34], thus in cases 
where Pnueli and Rosner’s model is undecidable. 

Yet another distributed version of Ramadge and Wonham’s problem is con¬ 
sidered in [^, this time for Petri nets. The problem is to compute local controllers 
that guarantee basic properties like e.g. deadlock avoidance. The limitation of 
this approach is that the algorithm may fail to find local controllers, although 
they exist. 

Game semantics and asynchronous games played on event structures are 
introduced in [33]. Such games are investigated in m from a game-theoretical 
viewpoint, showing a Borel determinacy result under some restrictions. 


Verification. As we already mentioned, automated verification of concurrent 
systems encounters major problems due to state explosion. One particularly effi¬ 
cient technique able to addresses this problem is known as partial order reduction 
(POR) [20137144) . It consists of restricting the exploration of the state space by 
avoiding the execution of similar, or equivalent runs. The notion of equivalence 
of runs used by POR is based on Mazurkiewicz traces. The efficiency of POR 
methods depends of course on the precise equivalence notion between executions. 
Recent variants, such as dynamic POR, work without storing explored states ex¬ 
plicitly and aim at improving the precision by computing additional information 
about (non)-equivalent executions [1]. 

There are other contexts in verification where analysis gets more efficient 
using equivalences based on Mazurkiewicz traces. One such setting is counter¬ 
example generation based on partial (Mazurkiewicz) traces instead of linear exe¬ 
cutions [6] . Previous work connecting concurrency issues and Mazurkiewicz trace 
theory concerns atomicity violations [12j . non-linearizability and sequential in¬ 
consistency [5]. 

Acknowledgments. Very special thanks to J&ome Leroux, Gabriele Puppis 
and Igor Walukiewicz for numerous comments on previous versions of this paper. 
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